[レポート]YAPC::Asia TOKYO 2015 Day 1＠五十嵐

五十嵐です。昨日に引き続き、YAPC::Asia Tokyo 2015 Day 1に参加してきました。今日もたくさんの熱いトークが繰り広げられており、中には入場制限がかかるような人気のトークもありました。私も一部、入場制限で見られなかったトークもありましたが、後日YouTubeで動画がアップされるそうなので、そちらを楽しみに待ちたいと思います。ということで、私が聴講したトークの様子をお届けします！

では早速。

Opening

Maki Daisuke氏よりオープニングの挨拶がありました。

ようこそYAPCへ！

会場の説明、進行の流れ、スポンサーの紹介などがあり、

ブログを書くまでがYAPCです！楽しみましょう！！

という挨拶でYAPC::Asia Tokyo 2015の1日目が幕を開けました。

Opening - YAPC::Asia Tokyo 2015

メリークリスマス！

Perlのパパことラリー・ウォール氏からは、Perl5からPerl6への過程で起きた数々の物語、そしてPerl6のリリース(予定)のアナウンスがありました。

毎年、Perl6のリリースはクリスマス(今年のとは言っていない)と言っているが、今年は本当にクリスマスまでにリリースの準備を進めているということです。 トークではPerl5からPer6への過程で起きたことを、数字にまつわる様々な偶然やトールキンの作品である「ホビットの冒険」と「指輪物語」になぞらえてお話をされていました。

・トールキンは「指輪物語」のパロットに「ホビットの冒険」のパロットを踏襲して、再設計し誤りを正した

・Perl6はPerl5のコアな部分は残しつつ、再設計し誤りを正した

またこんな言葉もおっしゃっていました。

成功裏なプログラム言語を作れるのは世界を構築できる人でなければならない

プログラム言語を作れる人はたくさんいるが、Perlのように成功するのはとても難しい。 たくさんの人に価値を与え、たくさんの仲間と協力し合い、そして未来を見せることができなければ成功はしないということです。

メリークリスマス！ - YAPC::Asia Tokyo 2015

TBD

Rubyの生みの親であるMatzことまつもとゆきひろ氏のトークです。

言語開発者として以下の3点をお話しされていました。

• Rubyの反省点
• Rubyが登場してから20年間でのアーキテクチャの変化
• 新しい言語の余地と新言語「Streem」

Rubyの反省点

唯一、Rubyの悪いところを指摘しても角が立たない立場(笑)のMatzから、今振り返るRubyの反省点について。

• Perlの影響を受けすぎた
• Rubyを開発し始めたときにロールモデルとしたのはPerlで、Perlに置き換わる言語を目指していた
• 組み込み変数$がtrueであれば大文字小文字を判別しない
• これによりプログラム全体の状態を変えてしまうことになってしまったのは良くなかった
• Lispの影響を受けすぎた
• FixnumとBignum、StringとSymbolのように似たようなクラスを明示的に分けてしまった
• これらはユーザに意識させる必要はなく内部的に自動で処理した方が良かった

Rubyが登場してから20年間でのアーキテクチャの変化

マルチコアがスタンダードになったことにより、プログラム言語に以下のような機能が求められるようになった

• スレッドセーフ
• GIL(Global Interpreter Lock)
• イミュータブル
• コンカレンシーモデル
• シェア・ボロー・モデル
• 持っているスレッドだけが変更権限を持つ
• スレッドを移動するときは権限ごと移動する
• データストリーム
• 高レベル抽象(DSL)
• 関数型言語の影響

また、アーキテクチャ振り子のようにいったりきたりしている

• サーバとクライアント
• はじめはサーバがすべての処理をしていた
• コンピュータの性能が上がるにつれPCが処理をするようになった
• Webの初期はブラウザではなくサーバがすべての処理をしていた
• 現在のWebはブラウザのJavaScriptがが多くの処理をするようになった
• パフォーマンスと生産性
• はじめはパフォーマンスが求められた
• コンピュータの性能が上がるにつれパフォーマンスよりも生産性が求められた
• Webが大規模になるにつれLLではパフォーマンスが足りなくなり、よりパフォーマンスを求められる

新しい言語の余地と新言語「Streem」

このようにアーキテクチャが変化することにより言語に求められることも変化する。

• マルチコアを生かすためシェルスクリプトが見直されているという話もある
• シェルスクリプトはパイプラインで繋ぐことでプロセスを実行するコアを分散させることができる
• でもシェルスクリプトはイケてない
• データを扱う場合は、データベースよりもデータフローが必要とされている

そこで開発を始めたのが新言語「Streem」

• Streemのアーキテクチャ
• 処理をパイプラインを組み立てる
• イベントループにデータの流れがあれば処理が実行される
• これらを名ずけて「ピタゴラスイッチ・プログラミング」

• Streemの特徴

• イミュータブルデータ
• エラーは基本無視
• パイプラインの組み立て時点での誤りはエラーとするが、イベントループ内のエラーは無視する
• Rubyの反省を活かす
• 「使い分け」を減らす
• 数字、文字列、配列しかない
• 数字は整数も少数も扱えるが、内部で自動的に変換処理される

いまのStreemはまだまだ小さな機能しかありませんが、MatzにはStreemが活躍する未来が見えているようでした。

TBD - YAPC::Asia Tokyo 2015

Yet Another Perl Cooking

moznion氏による料理ハックのトークです。

Programable Cookingに必要な3要素

• API Based
• スイッチをひねる、とろ火にする、といった手作業のIFから脱却する
• APIがあることで、ガジェットで料理ができる
• 再現性がある
• 誰がやっても同じ結果になる
• 自動性がある
• 自動的に料理ができる

それらを叶えてくれるガジェットに「Nomiku」がある

• Nomikuの機能
• 低温調理をするためのデバイス
• 水の温度を一定に保つことができる
• OSSのWebAPIがある

低温調理とは

• 真空調理方という
• 食材を水に沈めて加熱する調理法

低温調理Tips

• 肉
• 65度を超えると肉はパサつく
• ちゃんと加熱殺菌しないと危険
• コラーゲンは65度を越えると柔らかくなる
• 野菜
• 60度で煮ると硬くなる
• これを利用して60度で下茹でしてから高温で煮ると煮くずれしにくい

本当は「Nomuki」を使った発表をする予定だったが、届かなかったので同様のデバイスを自作した

必要な機能

• 水の温度をコントロール
• WebAPI

Raspberry Pi 2を使って自作した

• 仕組み
• 水温計で測った水温をGrowthForcastに一定間隔で投げる
• その温度が設定値より高ければヒーターの電源をOFFにし、低ければ電源をONにする

• 調理方法
• 真空パック機で肉を真空パックに封入して4時間待つだけ

参考書籍

• Cooking for Geeks
• 調理学

Yet Another Perl Cooking - YAPC::Asia Tokyo 2015

大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた

Osawa Kazuhiro氏によるMicroServicesを作る際のTipsです。

MicroServicesのメリット・デメリット

• メリット
• サービスをスケールしやすい
• 小さい単位の開発に集中できる
• デメリット
• サーバいっぱい
• コンポーネットいっぱい

スタートアップの場合はどうすべきか

• サービスの成長に合わせてMicroServicesにしていけば良い
• MVCを正しく作ることを心がける

中間的なサービスの場合はどうすべきか

• 他のサービスでも使いたくなったり、外の人に使ってもらいたくなったら切り出す
• DRYを考えればおのずとそうなる
• Deployの簡単さを維持することが大事

大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた - YAPC::Asia Tokyo 2015